Node / ReticulumProjects / Reticulum.git / files / docs / markdown / interfaces.md

Displaying Rendered • View raw • Download

Reticulum supports using many kinds of devices as networking interfaces, and

allows you to mix and match them in any way you choose. The number of distinct

network topologies you can create with Reticulum is more or less endless, but

common to them all is that you will need to define one or more interfaces

for Reticulum to use.

The following sections describe the interfaces currently available in Reticulum,

and gives example configurations for the respective interface types.

For a high-level overview of how networks can be formed over different interface

types, have a look at the Building Networks chapter of this

manual.

In addition to the built-in interface types, Reticulum is fully extensible with

custom, user- or community-supplied interfaces, and creating custom interface

modules is straightforward. Please see the custom interface

example for basic interface code to build upon.

The T383838AutoInterface enables communication with other discoverable Reticulum

nodes over any kind of local Ethernet or WiFi-based medium. Even though it uses IPv6 for peer

discovery, and UDP for packet transport, it does not need any functional IP

infrastructure like routers or DHCP servers, on your physical network.

If you have firewall software running on your computer, it may block traffic

required for T383838AutoInterface to work. If this is the case, you will have to

allow UDP traffic on port T38383829716 and T38383842671.

As long as there is at least some sort of switching medium present between peers (a

wired switch, a hub, a WiFi access point or similar, or simply two devices connected

directly by Ethernet cable), it will work without any configuration, setup or intermediary devices.

For T383838AutoInterface peer discovery to work, it’s also required that link-local

IPv6 support is available on your system, which it should be by default in all

current operating systems, both desktop and mobile.

Almost all current Ethernet and WiFi hardware will work without any kind

of configuration or setup with T383838AutoInterface, but a small subset of

devices turn on options that limit device-to-device communication by default,

resulting in T383838AutoInterface peer discovery being blocked. This issue is

most commonly seen on very cheap, ISP-supplied WiFi routers, and can sometimes

be turned off in the router configuration.

T282828

T8b949e# of an Auto Interface. It will allow communica-

T8b949e# tion with all other reachable devices on all

T8b949e# usable physical ethernet-based devices that

T8b949e# are available on the system.

Tff7b72[[Default Interface]]

Te6edf3type Tff7b72= Ta5d6ffAutoInterface

Te6edf3enabled Tff7b72= Ta5d6ffyes

T8b949e# This example demonstrates an more specifically

T8b949e# configured Auto Interface, that only uses spe-

T8b949e# cific physical interfaces, and has a number of

T8b949e# other configuration options set.

Tff7b72[[Default Interface]]

Te6edf3type Tff7b72= Ta5d6ffAutoInterface

Te6edf3enabled Tff7b72= Ta5d6ffyes

T8b949e# You can create multiple isolated Reticulum

T8b949e# networks on the same physical LAN by

T8b949e# specifying different Group IDs.

Te6edf3group_id Tff7b72= Ta5d6ffreticulum

T8b949e# You can also choose the multicast address type:

T8b949e# temporary (default, Temporary Multicast Address)

T8b949e# or permanent (Permanent Multicast Address)

Te6edf3multicast_address_type Tff7b72= Ta5d6ffpermanent

T8b949e# You can also select specifically which

T8b949e# kernel networking devices to use.

Te6edf3devices Tff7b72= Ta5d6ffwlan0,eth1

T8b949e# Or let AutoInterface use all suitable

T8b949e# devices except for a list of ignored ones.

Te6edf3ignored_devices Tff7b72= Ta5d6fftun0,eth0

If you are connected to the Internet with IPv6, and your provider will route

IPv6 multicast, you can potentially configure the Auto Interface to globally

autodiscover other Reticulum nodes within your selected Group ID. You can specify

the discovery scope by setting it to one of T383838link, T383838admin, T383838site,

T383838organisation or T383838global.

T282828

Te6edf3type Tff7b72= Ta5d6ffAutoInterface

Te6edf3enabled Tff7b72= Ta5d6ffyes

T8b949e# Configure global discovery

Te6edf3group_id Tff7b72= Ta5d6ffcustom_network_name

Te6edf3discovery_scope Tff7b72= Ta5d6ffglobal

T8b949e# Other configuration options

Te6edf3discovery_port Tff7b72= Ta5d6ff48555

Te6edf3data_port Tff7b72= Ta5d6ff49555

The Backbone interface is a very fast and resource efficient interface type, primarily

intended for interconnecting Reticulum instances over many different types of mediums.

It uses a kernel-event I/O backend, and can handle thousands of interfaces and/or clients

with relatively low system resource utilisation. **This interface type is currently only

supported on Linux and Android**.

The Backbone Interface is fully compatible with the T383838TCPServerInterface and T383838TCPClientInterface

types, and they can be used interchangably, and cross-connect with each other. On systems that support

T383838BackboneInterface, it is generally recommended to use it, unless you need specific options or

features that the TCP server and client interfaces provide.

While the goal is to support all socket types and I/O devices provided by the underlying

operating system, the initial release only provides support for TCP connections over IPv4

and IPv6.

For all types of connections over a T383838BackboneInterface, Reticulum will gracefully

handle intermittency, link loss, and connections that come and go.

The following examples illustrates various ways to set up T383838BackboneInterface listeners.

T282828

T8b949e# that listens for incoming connections on the

T8b949e# specified IP address and port number.

Tff7b72[[Backbone Listener]]

Te6edf3type Tff7b72= Ta5d6ffBackboneInterface

Te6edf3enabled Tff7b72= Ta5d6ffyes

Te6edf3listen_on Tff7b72= Ta5d6ff0.0.0.0

Te6edf3port Tff7b72= Ta5d6ff4242

T8b949e# Alternatively you can bind to a specific IP

Tff7b72[[Backbone Listener]]

Te6edf3type Tff7b72= Ta5d6ffBackboneInterface

Te6edf3enabled Tff7b72= Ta5d6ffyes

Te6edf3listen_on Tff7b72= Ta5d6ff10.0.0.88

Te6edf3port Tff7b72= Ta5d6ff4242

T8b949e# Or a specific network device

Tff7b72[[Backbone Listener]]

Te6edf3type Tff7b72= Ta5d6ffBackboneInterface

Te6edf3enabled Tff7b72= Ta5d6ffyes

Te6edf3device Tff7b72= Ta5d6ffeth0

Te6edf3port Tff7b72= Ta5d6ff4242

If you are using the interface on a device which has both IPv4 and IPv6 addresses available,

you can use the T383838prefer_ipv6 option to bind to the IPv6 address:

T282828

T8b949e# listening on the IPv6 address of a specified

T8b949e# kernel networking device.

Tff7b72[[Backbone Listener]]

Te6edf3type Tff7b72= Ta5d6ffBackboneInterface

Te6edf3enabled Tff7b72= Ta5d6ffyes

Te6edf3prefer_ipv6 Tff7b72= Ta5d6ffyes

Te6edf3device Tff7b72= Ta5d6ffeth0

Te6edf3port Tff7b72= Ta5d6ff4242

To use the T383838BackboneInterface over Yggdrasil, you

can simply specify the Yggdrasil T383838tun device and a listening port, like so:

T282828

T8b949e# listening for connections over Yggdrasil.

Tff7b72[[Yggdrasil Backbone Interface]]

Te6edf3type Tff7b72= Ta5d6ffBackboneInterface

Te6edf3enabled Tff7b72= Ta5d6ffyes

Te6edf3device Tff7b72= Ta5d6fftun0

Te6edf3port Tff7b72= Ta5d6ff4343

The following examples illustrates various ways to connect to remote T383838BackboneInterface listeners.

As noted above, T383838BackboneInterface interfaces can also connect to remote T383838TCPServerInterface,

and as such these interface types can be used interchangably.

T282828

T8b949e# connects to a remote listener.

Tff7b72[[Backbone Remote]]

Te6edf3type Tff7b72= Ta5d6ffBackboneInterface

Te6edf3enabled Tff7b72= Ta5d6ffyes

Te6edf3remote Tff7b72= Ta5d6ffamsterdam.connect.reticulum.network

Te6edf3target_port Tff7b72= Ta5d6ff4251

To connect to remotes over Yggdrasil, simply

specify the target Yggdrasil IPv6 address and port, like so:

T282828

Te6edf3type Tff7b72= Ta5d6ffBackboneInterface

Te6edf3enabled Tff7b72= Ta5d6ffyes

Te6edf3target_host Tff7b72= Ta5d6ff201:5d78:af73:5caf:a4de:a79f:3278:71e5

Te6edf3target_port Tff7b72= Ta5d6ff4343

Listener instances of T383838BackboneInterface will automatically block fast-flapping clients,

that repeatedly connect for a short amount of time, and then disconnect. Such behavior usually

occurs from clients trying to spam the network with announces or path requests, by connecting, dumping

a massive amount of requests, and then disconnecting in an attempt to bypass rate limits.

While such bypass attempts only have very limited effect on the amount of spam actually dumped (ingress limits

trigger immediately once a client exceeds rate limits), the behavior is often seen anyways, and

causes log noise and needless interface rotation. The fast-flapping block ensures such clients

are never allocated an interface on the transport instance.

Another common cause can simply be clients using implementations that are broken, or automated

scanning tools attempting to connect to the instance.

T282828

Te6edf3type Tff7b72= Ta5d6ffBackboneInterface

Te6edf3enabled Tff7b72= Ta5d6ffyes

Te6edf3listen_on Tff7b72= Ta5d6ff0.0.0.0

Te6edf3port Tff7b72= Ta5d6ff4242

T8b949e# Whether to enable blocking

Te6edf3block_fast_flapping Tff7b72= Ta5d6ffyes

T8b949e# How long an IP address stays

T8b949e# blocked, in minutes. Set to

T8b949e# 12 hours by default.

Te6edf3fast_flapping_block_time Tff7b72= Ta5d6ff720

T8b949e# The minimum time, in seconds,

T8b949e# an interface must stay connected

T8b949e# to be considered not fast-flapping.

Te6edf3fast_flapping_threshold Tff7b72= Ta5d6ff20

T8b949e# Amount of fast flaps a remote

T8b949e# IP can perform before having

T8b949e# blocking triggered.

Te6edf3fast_flapping_grace Tff7b72= Ta5d6ff5

The configuration options listed in the example above are the default values, and you do

not need to add them for automated blocking to work, but you can use them to change the

behavior from the defaults, if necessary.

The TCP Server interface is suitable for allowing other peers to connect over

the Internet or private IPv4 and IPv6 networks. When a TCP server interface has been

configured, other Reticulum peers can connect to it with a TCP Client interface.

T282828

T8b949e# It will listen for incoming connections on all IP

T8b949e# interfaces on port 4242.

Tff7b72[[TCP Server Interface]]

Te6edf3type Tff7b72= Ta5d6ffTCPServerInterface

Te6edf3enabled Tff7b72= Ta5d6ffyes

Te6edf3listen_ip Tff7b72= Ta5d6ff0.0.0.0

Te6edf3listen_port Tff7b72= Ta5d6ff4242

T8b949e# Alternatively you can bind to a specific IP

Tff7b72[[TCP Server Interface]]

Te6edf3type Tff7b72= Ta5d6ffTCPServerInterface

Te6edf3enabled Tff7b72= Ta5d6ffyes

Te6edf3listen_ip Tff7b72= Ta5d6ff10.0.0.88

Te6edf3listen_port Tff7b72= Ta5d6ff4242

T8b949e# Or a specific network device

Tff7b72[[TCP Server Interface]]

Te6edf3type Tff7b72= Ta5d6ffTCPServerInterface

Te6edf3enabled Tff7b72= Ta5d6ffyes

Te6edf3device Tff7b72= Ta5d6ffeth0

Te6edf3listen_port Tff7b72= Ta5d6ff4242

If you are using the interface on a device which has both IPv4 and IPv6 addresses available,

you can use the T383838prefer_ipv6 option to bind to the IPv6 address:

T282828

T8b949e# It will listen for incoming connections on the

T8b949e# specified IP address and port number.

Tff7b72[[TCP Server Interface]]

Te6edf3type Tff7b72= Ta5d6ffTCPServerInterface

Te6edf3enabled Tff7b72= Ta5d6ffyes

Te6edf3prefer_ipv6 Tff7b72= Ta5d6ffTrue

Te6edf3device Tff7b72= Ta5d6ffeth0

Te6edf3port Tff7b72= Ta5d6ff4242

To use the TCP Server Interface over Yggdrasil, you

can simply specify the Yggdrasil T383838tun device and a listening port, like so:

T282828

Te6edf3type Tff7b72= Ta5d6ffTCPServerInterface

Te6edf3enabled Tff7b72= Ta5d6ffyes

Te6edf3device Tff7b72= Ta5d6fftun0

Te6edf3listen_port Tff7b72= Ta5d6ff4343

The TCP interfaces support tunneling over I2P, but to do so reliably,

you must use the i2p_tunneled option:

T282828

Te6edf3type Tff7b72= Ta5d6ffTCPServerInterface

Te6edf3enabled Tff7b72= Ta5d6ffyes

Te6edf3listen_ip Tff7b72= Ta5d6ff127.0.0.1

Te6edf3listen_port Tff7b72= Ta5d6ff5001

Te6edf3i2p_tunneled Tff7b72= Ta5d6ffyes

In almost all cases, it is easier to use the dedicated T383838I2PInterface, but for complete

control, and using I2P routers running on external systems, this option also exists.

To connect to a TCP server interface, you can use the TCP client

interface. Many TCP Client interfaces from different peers can connect to the

same TCP Server interface at the same time.

The TCP interface types can also tolerate intermittency in the IP link layer.

This means that Reticulum will gracefully handle IP links that go up and down,

and restore connectivity after a failure, once the other end of a TCP interface reappears.

T282828

T8b949e# target_host can be a hostname or an IPv4 or IPv6 address.

Tff7b72[[TCP Client Interface]]

Te6edf3type Tff7b72= Ta5d6ffTCPClientInterface

Te6edf3enabled Tff7b72= Ta5d6ffyes

Te6edf3target_host Tff7b72= Ta5d6ff127.0.0.1

Te6edf3target_port Tff7b72= Ta5d6ff4242

To use the TCP Client Interface over Yggdrasil, simply

specify the target Yggdrasil IPv6 address and port, like so:

T282828

Te6edf3type Tff7b72= Ta5d6ffTCPClientInterface

Te6edf3enabled Tff7b72= Ta5d6ffyes

Te6edf3target_host Tff7b72= Ta5d6ff201:5d78:af73:5caf:a4de:a79f:3278:71e5

Te6edf3target_port Tff7b72= Ta5d6ff4343

It is also possible to use this interface type to connect via other programs

or hardware devices that expose a KISS interface on a TCP port, for example

software-based soundmodems. To do this, use the T383838kiss_framing option:

T282828

T8b949e# to a software TNC soundmodem on a KISS over TCP port.

Tff7b72[[TCP KISS Interface]]

Te6edf3type Tff7b72= Ta5d6ffTCPClientInterface

Te6edf3enabled Tff7b72= Ta5d6ffyes

Te6edf3kiss_framing Tff7b72= Ta5d6ffTrue

Te6edf3target_host Tff7b72= Ta5d6ff127.0.0.1

Te6edf3target_port Tff7b72= Ta5d6ff8001

Te6edf3fixed_mtu Tff7b72= Ta5d6ff500

Caution! Only use the KISS framing option when connecting to external devices

and programs like soundmodems and similar over TCP. When using the

T383838TCPClientInterface in conjunction with the T383838TCPServerInterface you should

never enable T383838kiss_framing, since this will disable internal reliability and

recovery mechanisms that greatly improves performance over unreliable and

intermittent TCP links.

For KISS devices that need only supports a particular MTU, you can use the

T383838fixed_mtu option.

The TCP interfaces support tunneling over I2P, but to do so reliably,

you must use the i2p_tunneled option:

T282828

Te6edf3type Tff7b72= Ta5d6ffTCPClientInterface

Te6edf3enabled Tff7b72= Ta5d6ffyes

Te6edf3target_host Tff7b72= Ta5d6ff127.0.0.1

Te6edf3target_port Tff7b72= Ta5d6ff5001

Te6edf3i2p_tunneled Tff7b72= Ta5d6ffyes

A UDP interface can be useful for communicating over IP networks, both

private and the internet. It can also allow broadcast communication

over IP networks, so it can provide an easy way to enable connectivity

with all other peers on a local area network.

Using broadcast UDP traffic has performance implications,

especially on WiFi. If your goal is simply to enable easy communication

with all peers in your local Ethernet broadcast domain, the

Auto Interface performs much better, and is even

easier to use.

T282828

T8b949e# local Reticulum peers over UDP.

Tff7b72[[UDP Interface]]

Te6edf3type Tff7b72= Ta5d6ffUDPInterface

Te6edf3enabled Tff7b72= Ta5d6ffyes

Te6edf3listen_ip Tff7b72= Ta5d6ff0.0.0.0

Te6edf3listen_port Tff7b72= Ta5d6ff4242

Te6edf3forward_ip Tff7b72= Ta5d6ff255.255.255.255

Te6edf3forward_port Tff7b72= Ta5d6ff4242

T8b949e# The above configuration will allow communication

T8b949e# within the local broadcast domains of all local

T8b949e# IP interfaces.

T8b949e# Instead of specifying listen_ip, listen_port,

T8b949e# forward_ip and forward_port, you can also bind

T8b949e# to a specific network device like below.

T8b949e# device = eth0

T8b949e# port = 4242

T8b949e# Assuming the eth0 device has the address

T8b949e# 10.55.0.72/24, the above configuration would

T8b949e# be equivalent to the following manual setup.

T8b949e# Note that we are both listening and forwarding to

T8b949e# the broadcast address of the network segments.

T8b949e# listen_ip = 10.55.0.255

T8b949e# listen_port = 4242

T8b949e# forward_ip = 10.55.0.255

T8b949e# forward_port = 4242

T8b949e# You can of course also communicate only with

T8b949e# a single IP address

T8b949e# listen_ip = 10.55.0.15

T8b949e# listen_port = 4242

T8b949e# forward_ip = 10.55.0.16

T8b949e# forward_port = 4242

The I2P interface lets you connect Reticulum instances over the

Invisible Internet Protocol. This can be

especially useful in cases where you want to host a globally reachable

Reticulum instance, but do not have access to any public IP addresses,

have a frequently changing IP address, or have firewalls blocking

inbound traffic.

Using the I2P interface, you will get a globally reachable, portable

and persistent I2P address that your Reticulum instance can be reached

at.

To use the I2P interface, you must have an I2P router running

on your system. The easiest way to achieve this is to download and

install the latest release

of the T383838i2pd package. For more details about I2P, see the

geti2p.net website.

When an I2P router is running on your system, you can simply add

an I2P interface to Reticulum:

T282828

Te6edf3type Tff7b72= Ta5d6ffI2PInterface

Te6edf3enabled Tff7b72= Ta5d6ffyes

Te6edf3connectable Tff7b72= Ta5d6ffyes

On the first start, Reticulum will generate a new I2P address for the

interface and start listening for inbound traffic on it. This can take

a while the first time, especially if your I2P router was also just

started, and is not yet well-connected to the I2P network. When ready,

you should see I2P base32 address printed to your log file. You can

also inspect the status of the interface using the T383838rnstatus utility.

To connect to other Reticulum instances over I2P, just add a comma-separated

list of I2P base32 addresses to the T383838peers option of the interface:

T282828

Te6edf3type Tff7b72= Ta5d6ffI2PInterface

Te6edf3enabled Tff7b72= Ta5d6ffyes

Te6edf3connectable Tff7b72= Ta5d6ffyes

Te6edf3peers Tff7b72= Ta5d6ff5urvjicpzi7q3ybztsef4i5ow2aq4soktfj7zedz53s47r54jnqq.b32.i2p

It can take anywhere from a few seconds to a few minutes to establish

I2P connections to the desired peers, so Reticulum handles the process

in the background, and will output relevant events to the log.

While the I2P interface is the simplest way to use

Reticulum over I2P, it is also possible to tunnel the TCP server and

client interfaces over I2P manually. This can be useful in situations

where more control is needed, but requires manual tunnel setup through

the I2P daemon configuration.

It is important to note that the two methods are interchangably compatible.

You can use the I2PInterface to connect to a TCPServerInterface that

was manually tunneled over I2P, for example. This offers a high degree

of flexibility in network setup, while retaining ease of use in simpler

use-cases.

To use Reticulum over LoRa, the RNode interface

can be used, and offers full control over LoRa parameters.

Radio frequency spectrum is a legally controlled resource, and legislation

varies widely around the world. It is your responsibility to be aware of any

relevant regulation for your location, and to make decisions accordingly.

T282828

T8b949e# using the RNode LoRa transceiver.

Tff7b72[[RNode LoRa Interface]]

Te6edf3type Tff7b72= Ta5d6ffRNodeInterface

T8b949e# Enable interface if you want use it!

Te6edf3enabled Tff7b72= Ta5d6ffyes

T8b949e# Serial port for the device

Te6edf3port Tff7b72= Ta5d6ff/dev/ttyUSB0

T8b949e# You can connect wirelessly to the

T8b949e# RNode device if it supports WiFi.

T8b949e# Connect by IP address

T8b949e# port = tcp://10.0.0.1

T8b949e# Or, connect by hostname

T8b949e# port = tcp://rnodef3b9.local

T8b949e# It is also possible to use BLE devices

T8b949e# instead of wired serial ports. The

T8b949e# target RNode must be paired with the

T8b949e# host device before connecting. BLE

T8b949e# devices can be connected by name,

T8b949e# BLE MAC address or by any available.

T8b949e# Connect to specific device by name

T8b949e# port = ble://RNode 3B87

T8b949e# Or by BLE MAC address

T8b949e# port = ble://F4:12:73:29:4E:89

T8b949e# Or connect to the first available,

T8b949e# paired device

T8b949e# port = ble://

T8b949e# Set frequency to 867.2 MHz

Te6edf3frequency Tff7b72= Ta5d6ff867200000

T8b949e# Set LoRa bandwidth to 125 KHz

Te6edf3bandwidth Tff7b72= Ta5d6ff125000

T8b949e# Set TX power to 7 dBm (5 mW)

Te6edf3txpower Tff7b72= Ta5d6ff7

T8b949e# Select spreading factor 8. Valid

T8b949e# range is 7 through 12, with 7

T8b949e# being the fastest and 12 having

T8b949e# the longest range.

Te6edf3spreadingfactor Tff7b72= Ta5d6ff8

T8b949e# Select coding rate 5. Valid range

T8b949e# is 5 throough 8, with 5 being the

T8b949e# fastest, and 8 the longest range.

Te6edf3codingrate Tff7b72= Ta5d6ff5

T8b949e# You can configure the RNode to send

T8b949e# out identification on the channel with

T8b949e# a set interval by configuring the

T8b949e# following two parameters.

T8b949e# id_callsign = MYCALL-0

T8b949e# id_interval = 600

T8b949e# For certain homebrew RNode interfaces

T8b949e# with low amounts of RAM, using packet

T8b949e# flow control can be useful. By default

T8b949e# it is disabled.

T8b949e# flow_control = False

T8b949e# It is possible to limit the airtime

T8b949e# utilisation of an RNode by using the

T8b949e# following two configuration options.

T8b949e# The short-term limit is applied in a

T8b949e# window of approximately 15 seconds,

T8b949e# and the long-term limit is enforced

T8b949e# over a rolling 60 minute window. Both

T8b949e# options are specified in percent.

T8b949e# airtime_limit_long = 1.5

T8b949e# airtime_limit_short = 33

For RNodes that support multiple LoRa transceivers, the RNode

Multi interface can be used to configure sub-interfaces individually.

Radio frequency spectrum is a legally controlled resource, and legislation

varies widely around the world. It is your responsibility to be aware of any

relevant regulation for your location, and to make decisions accordingly.

T282828

T8b949e# using the RNode LoRa transceiver.

Tff7b72[[RNode Multi Interface]]

Te6edf3type Tff7b72= Ta5d6ffRNodeMultiInterface

T8b949e# Enable interface if you want to use it!

Te6edf3enabled Tff7b72= Ta5d6ffyes

T8b949e# Serial port for the device

Te6edf3port Tff7b72= Ta5d6ff/dev/ttyACM0

T8b949e# You can configure the RNode to send

T8b949e# out identification on the channel with

T8b949e# a set interval by configuring the

T8b949e# following two parameters.

T8b949e# id_callsign = MYCALL-0

T8b949e# id_interval = 600

T8b949e# A subinterface

Tff7b72[[[High Datarate]]]

T8b949e# Subinterfaces can be enabled and disabled in of themselves

Te6edf3enabled Tff7b72= Ta5d6ffyes

T8b949e# Set frequency to 2.4GHz

Te6edf3frequency Tff7b72= Ta5d6ff2400000000

T8b949e# Set LoRa bandwidth to 1625 KHz

Te6edf3bandwidth Tff7b72= Ta5d6ff1625000

T8b949e# Set TX power to 0 dBm (0.12 mW)

Te6edf3txpower Tff7b72= Ta5d6ff0

T8b949e# The virtual port, only the manufacturer

T8b949e# or the person who wrote the board config

T8b949e# can tell you what it will be for which

T8b949e# physical hardware interface

Te6edf3vport Tff7b72= Ta5d6ff1

T8b949e# Select spreading factor 5. Valid

T8b949e# range is 5 through 12, with 5

T8b949e# being the fastest and 12 having

T8b949e# the longest range.

Te6edf3spreadingfactor Tff7b72= Ta5d6ff5

T8b949e# Select coding rate 5. Valid range

T8b949e# is 5 throough 8, with 5 being the

T8b949e# fastest, and 8 the longest range.

Te6edf3codingrate Tff7b72= Ta5d6ff5

T8b949e# It is possible to limit the airtime

T8b949e# utilisation of an RNode by using the

T8b949e# following two configuration options.

T8b949e# The short-term limit is applied in a

T8b949e# window of approximately 15 seconds,

T8b949e# and the long-term limit is enforced

T8b949e# over a rolling 60 minute window. Both

T8b949e# options are specified in percent.

T8b949e# airtime_limit_long = 100

T8b949e# airtime_limit_short = 100

Tff7b72[[[Low Datarate]]]

T8b949e# Subinterfaces can be enabled and disabled in of themselves

Te6edf3enabled Tff7b72= Ta5d6ffyes

T8b949e# Set frequency to 865.6 MHz

Te6edf3frequency Tff7b72= Ta5d6ff865600000

T8b949e# The virtual port, only the manufacturer

T8b949e# or the person who wrote the board config

T8b949e# can tell you what it will be for which

T8b949e# physical hardware interface

Te6edf3vport Tff7b72= Ta5d6ff0

T8b949e# Set LoRa bandwidth to 125 KHz

Te6edf3bandwidth Tff7b72= Ta5d6ff125000

T8b949e# Set TX power to 0 dBm (0.12 mW)

Te6edf3txpower Tff7b72= Ta5d6ff0

T8b949e# Select spreading factor 7. Valid

T8b949e# range is 5 through 12, with 5

T8b949e# being the fastest and 12 having

T8b949e# the longest range.

Te6edf3spreadingfactor Tff7b72= Ta5d6ff7

T8b949e# Select coding rate 5. Valid range

T8b949e# is 5 throough 8, with 5 being the

T8b949e# fastest, and 8 the longest range.

Te6edf3codingrate Tff7b72= Ta5d6ff5

T8b949e# It is possible to limit the airtime

T8b949e# utilisation of an RNode by using the

T8b949e# following two configuration options.

T8b949e# The short-term limit is applied in a

T8b949e# window of approximately 15 seconds,

T8b949e# and the long-term limit is enforced

T8b949e# over a rolling 60 minute window. Both

T8b949e# options are specified in percent.

T8b949e# airtime_limit_long = 100

T8b949e# airtime_limit_short = 100

Reticulum can be used over serial ports directly, or over any device with a

serial port, that will transparently pass data. Useful for communicating

directly over a wire-pair, or for using devices such as data radios and lasers.

T282828

Te6edf3type Tff7b72= Ta5d6ffSerialInterface

Te6edf3enabled Tff7b72= Ta5d6ffyes

T8b949e# Serial port for the device

Te6edf3port Tff7b72= Ta5d6ff/dev/ttyUSB0

T8b949e# Set the serial baud-rate and other

T8b949e# configuration parameters.

Te6edf3speed Tff7b72= Ta5d6ff115200

Te6edf3databits Tff7b72= Ta5d6ff8

Te6edf3parity Tff7b72= Ta5d6ffnone

Te6edf3stopbits Tff7b72= Ta5d6ff1

Using this interface, Reticulum can use any program as an interface via stdin and

stdout. This can be used to easily create virtual interfaces, or to interface with

custom hardware or other systems.

T282828

Te6edf3type Tff7b72= Ta5d6ffPipeInterface

Te6edf3enabled Tff7b72= Ta5d6ffyes

T8b949e# External command to execute

Te6edf3command Tff7b72= Ta5d6ffnetcat -l 5757

T8b949e# Optional respawn delay, in seconds

Te6edf3respawn_delay Tff7b72= Ta5d6ff5

Reticulum will write all packets to stdin of the T383838command option, and will

continuously read and scan its stdout for Reticulum packets. If T383838EOF is reached,

Reticulum will try to respawn the program after waiting for T383838respawn_interval seconds.

With the KISS interface, you can use Reticulum over a variety of packet

radio modems and TNCs, including OpenModem.

KISS interfaces can also be configured to periodically send out beacons

for station identification purposes.

Radio frequency spectrum is a legally controlled resource, and legislation

varies widely around the world. It is your responsibility to be aware of any

relevant regulation for your location, and to make decisions accordingly.

T282828

Te6edf3type Tff7b72= Ta5d6ffKISSInterface

Te6edf3enabled Tff7b72= Ta5d6ffyes

T8b949e# Serial port for the device

Te6edf3port Tff7b72= Ta5d6ff/dev/ttyUSB1

T8b949e# Set the serial baud-rate and other

T8b949e# configuration parameters.

Te6edf3speed Tff7b72= Ta5d6ff115200

Te6edf3databits Tff7b72= Ta5d6ff8

Te6edf3parity Tff7b72= Ta5d6ffnone

Te6edf3stopbits Tff7b72= Ta5d6ff1

T8b949e# Set the modem preamble.

Te6edf3preamble Tff7b72= Ta5d6ff150

T8b949e# Set the modem TX tail.

Te6edf3txtail Tff7b72= Ta5d6ff10

T8b949e# Configure CDMA parameters. These

T8b949e# settings are reasonable defaults.

Te6edf3persistence Tff7b72= Ta5d6ff200

Te6edf3slottime Tff7b72= Ta5d6ff20

T8b949e# You can configure the interface to send

T8b949e# out identification on the channel with

T8b949e# a set interval by configuring the

T8b949e# following two parameters. The KISS

T8b949e# interface will only ID if the set

T8b949e# interval has elapsed since it's last

T8b949e# actual transmission. The interval is

T8b949e# configured in seconds.

T8b949e# This option is commented out and not

T8b949e# used by default.

T8b949e# id_callsign = MYCALL-0

T8b949e# id_interval = 600

T8b949e# Whether to use KISS flow-control.

T8b949e# This is useful for modems that have

T8b949e# a small internal packet buffer, but

T8b949e# support packet flow control instead.

Te6edf3flow_control Tff7b72= Ta5d6fffalse

If you’re using Reticulum on amateur radio spectrum, you might want to

use the AX.25 KISS interface. This way, Reticulum will automatically

encapsulate it’s traffic in AX.25 and also identify your stations

transmissions with your callsign and SSID.

Only do this if you really need to! Reticulum doesn’t need the AX.25

layer for anything, and it incurs extra overhead on every packet to

encapsulate in AX.25.

A more efficient way is to use the plain KISS interface with the

beaconing functionality described above.

Radio frequency spectrum is a legally controlled resource, and legislation

varies widely around the world. It is your responsibility to be aware of any

relevant regulation for your location, and to make decisions accordingly.

T282828

Te6edf3type Tff7b72= Ta5d6ffAX25KISSInterface

T8b949e# Set the station callsign and SSID

Te6edf3callsign Tff7b72= Ta5d6ffNO1CLL

Te6edf3ssid Tff7b72= Ta5d6ff0

T8b949e# Enable interface if you want use it!

Te6edf3enabled Tff7b72= Ta5d6ffyes

T8b949e# Serial port for the device

Te6edf3port Tff7b72= Ta5d6ff/dev/ttyUSB2

T8b949e# Set the serial baud-rate and other

T8b949e# configuration parameters.

Te6edf3speed Tff7b72= Ta5d6ff115200

Te6edf3databits Tff7b72= Ta5d6ff8

Te6edf3parity Tff7b72= Ta5d6ffnone

Te6edf3stopbits Tff7b72= Ta5d6ff1

T8b949e# Set the modem preamble. A 150ms

T8b949e# preamble should be a reasonable

T8b949e# default, but may need to be

T8b949e# increased for radios with slow-

T8b949e# opening squelch and long TX/RX

T8b949e# turnaround

Te6edf3preamble Tff7b72= Ta5d6ff150

T8b949e# Set the modem TX tail. In most

T8b949e# cases this should be kept as low

T8b949e# as possible to not waste airtime.

Te6edf3txtail Tff7b72= Ta5d6ff10

T8b949e# Configure CDMA parameters. These

T8b949e# settings are reasonable defaults.

Te6edf3persistence Tff7b72= Ta5d6ff200

Te6edf3slottime Tff7b72= Ta5d6ff20

T8b949e# Whether to use KISS flow-control.

T8b949e# This is useful for modems with a

T8b949e# small internal packet buffer.

Te6edf3flow_control Tff7b72= Ta5d6fffalse

Reticulum includes a powerful system for publishing your local interfaces to the wider network, allowing other peers to discover, validate, and automatically connect to them. This feature is particularly useful for creating decentralized networks where peers can dynamically find entrypoints, such as public Internet gateways or local radio access points, without relying on static configuration files or centralized directories.

When an interface is made discoverable, your Reticulum instance will periodically broadcast an announce packet containing the connection details and parameters required for other peers to establish a connection. These announces are propagated over the network using the standard Reticulum announce mechanism using the T383838rnstransport.discovery.interface destination type.

To use the interface discovery functionality, the T383838LXMF module must be installed in your Python environment. You can install it using pip:

T282828

Interface discovery is enabled on a per-interface basis. To make a specific interface discoverable, you must add the T383838discoverable option to that interface’s configuration block and set it to T383838yes.

T282828

Te6edf3type Tff7b72= Ta5d6ffBackboneInterface

Te6edf3...

Te6edf3discoverable Tff7b72= Ta5d6ffyes

Once enabled, Reticulum will automatically handle the generation, signing, stamping, and broadcasting of the discovery announces. It is not required to enable Transport to publish interface discovery information, but for most use cases where you want others to connect to you, you will likely want T383838enable_transport set to T383838yes in the T383838[reticulum] section of your configuration.

When T383838discoverable is enabled, a variety of additional options become available to control how the interface is presented to the network. These parameters allow you to fine-tune the metadata, security requirements, and visibility of your interface.

T383838discovery_name

: A human-readable name for the interface. This name will be displayed to users on remote systems when they list discovered interfaces. If not specified, the interface name (the section header) will be used.

T383838announce_interval

: The interval in minutes between successive discovery announces for this interface. Default is 360 minutes (6 hours). For stable, long-running infrastructure, higher intervals (12 to 22 hours) are usually sufficient and reduce network load. Minimum allowed value is 5 minutes (but expect to have your announces throttled if using intervals below one hour).

T383838reachable_on

: Specifies the address that remote peers should use to connect to this interface.

• For TCP and Backbone interfaces, this is typically the public IP address or hostname. Do not include the port, this is fetched automatically from the interface.

• For I2P interfaces, this is usually the I2P T383838b32 address. This value is fetched automatically from the T383838I2PInterface once it is up and connected to the I2P network, so you should not set this manually, unless you absolutely know what you’re doing.

Dynamic Resolution: This option also accepts a path to an external executable script or binary. If a path is provided, Reticulum will execute the script and use its T383838stdout as the reachability address. This is useful for devices behind dynamic DNS, NATs, or complex cloud environments where the external IP is not known locally. The script must simply print the address to stdout and exit.

When using an executable script for T383838reachable_on, Reticulum expects the script to output only the IP address or hostname to T383838stdout, followed by a newline character. Any additional output or errors may cause the resolution to fail. Ensure the script has executable permissions and is robust against temporary network failures.

A minimal example of a script that resolves the externally available, public IP of an internet-connected system could look like this:

T282828

curl -s ip.me

Tffa657exit Te6edf3$?

On a real system, you should make the script robust enough to deal with intermittent Internet or service failures, such that the script always returns a sensible value, or if not possible at least exits with a non-zero exit return code, so Reticulum knows the output is invalid.

T383838discovery_stamp_value

: Defines the proof-of-work difficulty for the cryptographic stamp included in the announce. This value acts as a cost barrier to prevent network flooding. The default value is T38383814. Increasing this value makes it computationally more expensive to generate an announce, which can be useful to prevent spam on very large networks, but it also increases CPU load on your system when generating announces. Stamps are cached, and only generated if interface information changes, or at instance restart. If you have the computational resources, it is generally advisable to use as high a stamp value as possible.

T383838discovery_encrypt

: If set to T383838yes, the discovery announce payload will be encrypted. To decrypt the announce, remote peers must possess the network identity configured for your instance (see T383838network_identity in the T383838[reticulum] section). This allows you to publish private interfaces that are only discoverable to specific trusted networks.

If you enable T383838discovery_encrypt but do not configure a valid T383838network_identity in the T383838[reticulum] section of your configuration, Reticulum will abort the interface discovery announce. Encryption requires a valid network identity key to function.

T383838publish_ifac

: If set to T383838yes, the Interface Access Code (IFAC) name and passphrase for this interface will be included in the discovery announce. This allows peers to automatically configure the correct authentication parameters when connecting to the interface.

T383838latitude, T383838longitude, T383838height

: Optional physical coordinates for the interface. These are useful for mapping discovered interfaces geographically or for clients to automatically select the nearest access point. Coordinates should be in decimal degrees, height in meters above mean sea level.

T383838location_cmd

: Optional path to executable or script that returns the physical coordinates for the interface. This can be used instead of manually setting T383838latitude, T383838longitude and T383838height. Reticulum expects the script to output the location data to T383838stdout on a single line, separated by commas, with values as floating point numbers in the format T383838LAT, LON, HEIGHT. Coordinates should be in decimal degrees, height in meters above mean sea level.

The height value for interface discovery is specified in height above mean sea level! This is the geoid-corrected height value, and is distinct from GPS altitude. If you manually specify height, it will typically be set to what you find on a topographical map. If you are using a script to output the location data, make sure that you are using the geoid-corrected altitude, not height above the GPS ellipsoid. Most GPS systems will make both figures available.

For physical radio interfaces like T383838RNodeInterface or T383838KISSInterface, the following optional parameters allow you to broadcast the operating frequency and characteristics, allowing clients to verify compatibility before connecting:

T383838discovery_frequency

: The operating frequency in Hz. Auto-configured on RNode interfaces. Necessary on KISS-based radio interfaces and T383838TCPClientInterfaces connecting to radio modems.

T383838discovery_bandwidth

: The signal bandwidth in Hz. Auto-configured on RNode interfaces. Useful on KISS-based radio interfaces and T383838TCPClientInterfaces connecting to radio modems.

T383838discovery_modulation

: The modulation type or scheme. Auto-configured on RNode interfaces, but highly advisable to include on other radio-based interfaces.

When you enable discovery on an interface, Reticulum enforces certain interface modes to ensure the interface is actually useful for remote peers.

If an interface is configured as T383838discoverable, but its mode is not explicitly set to T383838gateway (for server-style interfaces like T383838BackboneInterface or T383838TCPServerInterface) or T383838access_point (for radio interfaces like T383838RNodeInterface), Reticulum will automatically configure the appropriate mode and log a notice.

For example, if you enable discovery on a T383838RNodeInterface without specifying the mode, Reticulum will automatically set it to T383838access_point mode.

When making interfaces discoverable, you are effectively broadcasting an invitation to connect to your system. It is important to understand the security implications of the configuration options you choose.

If you enable T383838publish_ifac = yes, your interface’s authentication passphrase will be included in the announce. If you are operating a public network and want anyone to connect, this is acceptable. However, if you wish to restrict access to a specific group of users, you must enable T383838discovery_encrypt = yes. This ensures that only peers possessing the correct T383838network_identity can decode the passphrase.

A discoverable interface announces its presence, location (if configured), and capabilities to the network. Even if the connection details are encrypted, the fact that a connectable node exists within a certain network becomes public information. In high-security or scenarios requiring operational secrecy, consider the implications of advertising your infrastructure’s existence.

Below is an example configuration for a public backbone gateway. This configuration publishes a high-value, publicly discoverable interface, that anyone can connect to.

T282828

Te6edf3type Tff7b72= Ta5d6ffBackboneInterface

Te6edf3mode Tff7b72= Ta5d6ffgateway

Te6edf3listen_on Tff7b72= Ta5d6ff0.0.0.0

Te6edf3port Tff7b72= Ta5d6ff4242

T8b949e# Enable Discovery

Te6edf3discoverable Tff7b72= Ta5d6ffyes

T8b949e# Interface Details

Te6edf3discovery_name Tff7b72= Ta5d6ffRegion A Public Entrypoint

Te6edf3announce_interval Tff7b72= Ta5d6ff720

T8b949e# Use external script to resolve dynamic IP

Te6edf3reachable_on Tff7b72= Ta5d6ff/usr/local/bin/get_external_ip.sh

T8b949e# Generate high stamp value

Te6edf3discovery_stamp_value Tff7b72= Ta5d6ff24

T8b949e# Optional location data

Te6edf3latitude Tff7b72= Ta5d6ff51.99714

Te6edf3longitude Tff7b72= Ta5d6ff-0.74195

Te6edf3height Tff7b72= Ta5d6ff15

The next example create an encrypted discovery-enabled interface, requiring a specific network identity to decode, and includes IFAC credentials for seamless authentication.

T282828

Te6edf3type Tff7b72= Ta5d6ffBackboneInterface

Te6edf3mode Tff7b72= Ta5d6ffgateway

Te6edf3listen_on Tff7b72= Ta5d6ff0.0.0.0

Te6edf3port Tff7b72= Ta5d6ff5858

Te6edf3network_name Tff7b72= Ta5d6ffinternal_1

Te6edf3passphrase Tff7b72= Ta5d6ffMevpekyafshak5Wr

T8b949e# Enable Discovery

Te6edf3discoverable Tff7b72= Ta5d6ffyes

T8b949e# Interface Details

Te6edf3discovery_name Tff7b72= Ta5d6ffRegion A Private Backbone

Te6edf3announce_interval Tff7b72= Ta5d6ff720

T8b949e# Use external script to resolve dynamic IP

Te6edf3reachable_on Tff7b72= Ta5d6ff/usr/local/bin/get_external_ip.sh

T8b949e# Target stamp value

Te6edf3discovery_stamp_value Tff7b72= Ta5d6ff22

T8b949e# Encrypt announces for our network only

Te6edf3discovery_encrypt Tff7b72= Ta5d6ffyes

T8b949e# Include credentials so trusted

T8b949e# peers can connect automatically

Te6edf3publish_ifac Tff7b72= Ta5d6ffyes

T8b949e# Optional location data

Te6edf3latitude Tff7b72= Ta5d6ff34.06915

Te6edf3longitude Tff7b72= Ta5d6ff-118.44318

Te6edf3height Tff7b72= Ta5d6ff15

In the T383838[reticulum] section of your configuration, you would define the network identity used for encryption as follows:

T282828

Te6edf3...

T8b949e# The identity used to sign/encrypt discovery announces

Te6edf3network_identity Tff7b72= Ta5d6ff~/.reticulum/storage/identities/my_network_identity

Te6edf3...

With these configuration options applied, your Reticulum instance will actively participate in the network’s discovery ecosystem. Other peers running Reticulum with discovery enabled will be able to see your interface, validate its cryptographic stamp, and (depending on their configuration) automatically connect to it.

For information on how to use these discovered interfaces and configure your system to auto-connect to them, refer to the Discovering Interfaces chapter.

A number of general configuration options are available on most interfaces.

These can be used to control various aspects of interface behaviour.

│ The T383838enabled option tells Reticulum whether or not to bring up the interface. Defaults to T383838False.

│ For any interface to be brought up, the T383838enabled option must be set to T383838True or T383838Yes. The T383838mode

│ option allows selecting the high-level behaviour of the interface from a number of options. > -

│ The default value is T383838full. In this mode, all discovery, > meshing and transport functionality is

│ available. > - In the T383838access_point (or shorthand T383838ap) mode, the > interface will operate as a

│ network access point. In this > mode, announces will not be automatically broadcasted on > the

│ interface, and paths to destinations on the interface > will have a much shorter expiry time.

│ This mode is useful > for creating interfaces that are mostly quiet, unless when > someone is

│ actually using them. An example of this could > be a radio interface serving a wide area, where

│ users are > expected to connect momentarily, use the network, and then > disappear again. > - See

│ the Interface │ Modes

│ section > below for a reference on additional modes. The T383838gravity option specifies the pathing

│ pathing affinity, and negative values decrease it. The T383838outgoing option sets whether an interface

│ is allowed to transmit. Defaults to T383838True. If set to T383838False or T383838No the interface will only receive

│ data, and never transmit. The T383838network_name option sets the virtual network name for the

│ or medium. The T383838passphrase option sets an authentication passphrase on the interface. This option

│ can be used in conjunction with the T383838network_name option, or be used alone. The T383838ifac_size option

│ option. In normal usage, this option should not be changed from the default. The T383838announce_cap

│ option lets you configure the maximum bandwidth to allocate, at any given time, to propagating

│ announces and other network upkeep traffic. It is configured at 2% by default, and should

│ normally not need to be changed. Can be set to any value between T3838381 and T383838100. > If an interface

│ > Destinations that are rapidly re-announcing will be down-prioritised > further. Trying to get

│ > This means that it is always beneficial to select a balanced > announce rate, and not announce

│ more often than is actually necesarry > for your application to function. The T383838bitrate option

│ option, to set the interface speed in bits per second. The T383838bootstrap_only option designates an

│ interface as a temporary bridge for initial connectivity. If this option is enabled, the

│ interface will be monitored and automatically detached once the number of auto-connected

│ interfaces reaches the limit configured by T383838autoconnect_discovered_interfaces. This is

│ particularly useful for using a slow or expensive connection (such as a single LoRa link or a

│ remote TCP tunnel) solely to discover better local infrastructure, which then supersedes the

│ bootstrap interface. The T383838recursive_prs option allows you to enable recursive path discovery on

│ will attempt to recursively discover paths for path requests received on this interface. The

│ T383838announces_from_internal option controls whether any announces received on an T383838internal mode

│ interface will propagate out on the interface this option is set on. Note that this controls

│ announce propagation; even if announces do not propagate out when received, paths to destinations

│ on T383838internal mode interfaces may still be resolvable by means of path requests. To allow an

│ interface that would otherwise not* propagate announces to T383838internal mode interfaces to do so, you

│ can configure the T383838announces_to_internal option to T383838True.

The optional T383838mode setting is available on all interfaces, and allows

selecting the high-level behaviour of the interface from a number of modes.

These modes affect how Reticulum selects paths in the network, how announces

are propagated, how long paths are valid and how paths are discovered.

Configuring modes on interfaces is not strictly necessary, but can be useful

when building or connecting to more complex networks. If your Reticulum

instance is not running a Transport Node, it is rarely useful to configure

interface modes, and in such cases interfaces should generally be left in

the default mode.

│ The default mode is T383838full. In this mode, all discovery, meshing and transport functionality is

│ activated. The T383838gateway mode (or shorthand T383838gw) also has all discovery, meshing and transport

│ functionality available, but will additionally try to discover unknown paths on behalf of other

│ nodes residing on the T383838gateway interface. If Reticulum receives a path request for an unknown

│ destination, from a node on a T383838gateway interface, it will try to discover this path via all other

│ active interfaces, and forward the discovered path to the requestor if one is found. If you want

│ to allow other nodes to widely resolve paths or connect to a network via an interface, it might

│ be useful to put it in this mode. By creating a chain of T383838gateway interfaces, other nodes will be

│ able to immediately discover paths to any destination along the chain. Please note! It is the

│ interface facing the clients that must be put into T383838gateway mode for this to work, not the

│ interface facing the wider network (for this, the T383838boundary mode can be useful, though). In the

│ are expected to connect momentarily, use the network, and then disappear again. The T383838roaming mode

│ should be used on interfaces that are roaming (physically mobile), seen from the perspective of

│ other nodes in the network. As an example, if a vehicle is equipped with an external LoRa

│ interface, and an internal, WiFi-based interface, that serves devices that are moving with the

│ vehicle, the external LoRa interface should be configured as T383838roaming, and the internal interface

│ can be left in the default mode. With transport enabled, such a setup will allow all internal

│ devices to reach each other, and all other devices that are available on the LoRa side of the

│ network, when they are in range. Devices on the LoRa side of the network will also be able to

│ reach devices internal to the vehicle, when it is in range. Paths via T383838roaming interfaces also

│ expire faster. The purpose of the T383838boundary mode is to specify interfaces that establish

│ connecting over the Internet should be set to T383838boundary mode. The T383838internal mode designates

│ interfaces that belong to a network different from any marked as T383838boundary. Announces from a

│ T383838boundary interface will not propagate to interfaces set as T383838internal, but announces will propagate

│ from T383838internal to T383838boundary. Devices on the T383838internal side of the network will still be able to

│ resolve paths to destinations across the boundary when needed, since recursive path requests are

│ enabled for T383838internal mode interfaces by default.

For a table describing the impact of all modes on announce propagation,

please see the Announce Propagation Rules section.

The built-in announce control mechanisms and the default T383838announce_cap

option described above are sufficient most of the time, but in some cases,

especially on fast interfaces, or when connecting to large public networks,

it may be useful to control the target announce rate.

Using the T383838announce_rate_target, T383838announce_rate_grace and T383838announce_rate_penalty

options, this can be done on a per-interface basis, or by setting instance-wide defaults.

When configured, this moderates the *rate at which received announces are

re-broadcasted to other interfaces*.

│ The T383838announce_rate_target option sets the minimum amount of time, in seconds, that should pass

│ means that announces received on this interface will only be re-transmitted and propagated to

│ other interfaces once every hour, no matter how often they are received. The optional

│ T383838announce_rate_grace defines the number of times a destination can violate the announce rate

│ before the target rate is enforced. * The optional T383838announce_rate_penalty configures an extra

│ amount of time that is added to the normal rate target. As an example, if a penalty of T3838387200

│ seconds is defined, once the rate target is enforced, the destination in question will only have

│ its announces propagated every 3 hours, until it lowers its actual announce rate to within the

│ target.

You can also configure default announce rate parameters for all interfaces that

do not have these parameters set explicitly by setting the T383838default_ar_target

T383838default_ar_penalty and T383838default_ar_grace options in the T383838[reticulum]

section of the configuration file. If any of these options are set, they will

automatically be applied to any interface if transport is enabled, and the

interface does not have the parameters set explicitly.

For auto-connected interfaces, sensible default announce rate control parameters

will always be set, even if the defaults are not configured explicitly, but

if you set the defaults, auto-connected interfaces will adhere to these as well.

These mechanisms, in conjunction with the T383838annouce_cap mechanisms mentioned

above means that it is essential to select a balanced announce strategy for

your destinations. The more balanced you can make this decision, the easier

it will be for your destinations to make it into slower networks, or networks that

are many hops away.

Statistics and information about announce rates can be viewed using the

T383838rnpath -r and T383838rnstatus -A commands.

It is important to note, that while there is no one right or wrong way to set up announce

rates, it should generally not be necessary to announce any kind of destination.

more often than once every few hours. Most applications can announce simply when

the application starts, and then only once every 6 hours or so.

If you’re designing an application where you think you need to annonuce more

often than once an hour, you’re most likely doing something wrong.

Slower networks will naturally tend towards using less frequent announces to

conserve bandwidth, while very fast networks can support applications that

need more frequent announces. Reticulum implements these mechanisms to ensure

that a large span of network types can seamlessly co-exist and interconnect.

On public interfaces, where anyone may connect and announce new destinations,

it can be useful to control the rate at which announces for new destinations are

processed.

If a large influx of announces for newly created or previously unknown destinations

occur within a short amount of time, Reticulum will place these announces on hold,

so that announce traffic for known and previously established destinations can

continue to be processed without interruptions.

After the burst subsides, and an additional waiting period has passed, the held

announces will be released at a slow rate, until the hold queue is cleared. This

also means, that should a node decide to connect to a public interface, announce

a large amount of bogus destinations, and then disconnect, these destination will

never make it into path tables and waste network bandwidth on retransmitted

announces.

It’s important to remember that the ingress control works at the level of *individual

sub-interfaces*. As an example, this means that one client on a TCP Server Interface

cannot disrupt processing of incoming announces for other connected clients on the same

TCP Server Interface. All other clients on the same interface

will still have new announces processed without interruption.

By default, Reticulum will handle this automatically, and ingress announce

control will be enabled on interface where it is sensible to do so. It should

generally not be neccessary to modify the ingress control configuration,

but all the parameters are exposed for configuration if needed.

│ The T383838ingress_control option tells Reticulum whether or not to enable ingress control on the

│ interface. Defaults to T383838True. The T383838ic_new_time option configures how long (in seconds) an

│ interface is considered newly spawned. Defaults to T3838382*60*60 seconds. This option is useful on

│ publicly accessible interfaces that spawn new sub-interfaces when a new client connects. The

│ interfaces. Defaults to T3838383.5 announces per second. The T383838ic_burst_freq option sets the maximum

│ announce ingress frequency for other interfaces. Defaults to T38383812 announces per second. > If an

│ temporarily held in a queue, and > not processed until later. The T383838ic_max_held_announces option

│ announces will be dropped. Defaults to T383838256 announces. The T383838ic_burst_hold option sets how much

│ time (in seconds) must pass after the burst frequency drops below its threshold, for the announce

│ burst to be considered cleared. Defaults to T38383860 seconds. The T383838ic_burst_penalty option sets how

│ start being released from the queue. Defaults to T3838385*60 seconds. The T383838ic_held_release_interval

│ option sets how much time (in seconds) must pass between releasing each held announce from the

│ queue. Defaults to T38383830 seconds.

All of the above settings can be configured both as instance-wide defaults

under the T383838[reticulum] section of the configuration file, or on a per-

interface basis under the relevant interface configuration section.

In addition the announce controls for newly created destination, Reticulum will also

monitor incoming path request activity, and enforce burst controls if per-client rates

exceed configured limits. Once path request burst control is activated on an

interface, path requests will no longer be propagated further on the network.

As with announce burst control, this happens on a per sub-interface basis. One

client connecting to a public gateway will not be able to disrupt path request

processing for other clients.

Applications that send large amounts of unnecessary path requests will very

quickly get rate limited by transport nodes, and the entire system they are

running on will not be able to resolve any paths on the network, until the

burst subsides and hold period expires. Do not write applications like

this. Only request paths for destinations you need to communicate with.

By default, Reticulum will handle this automatically, and ingress path request

control will be enabled on interface where it is sensible to do so. It should

generally not be neccessary to modify the ingress control configuration,

but all the parameters are exposed for configuration if needed.

│ The T383838ingress_control option tells Reticulum whether or not to enable ingress control on the

│ interface. Defaults to T383838True. The T383838ic_new_time option configures how long (in seconds) an

│ interface is considered newly spawned. Defaults to T3838382*60*60 seconds. This option is useful on

│ publicly accessible interfaces that spawn new sub-interfaces when a new client connects. The

│ interfaces. Defaults to T3838383 path requests per second. The T383838ic_pr_burst_freq option sets the maximum

│ path request ingress frequency for other interfaces. Defaults to T3838388 path requests per second. > If

│ traverse the network further. The T383838egress_control option enables hard-limiting path request

│ egress control per-interface. Defaults to T383838False The T383838ec_pr_freq option sets the hard limit for

│ outbound path requests per second on a given interface.

All of the above settings can be configured both as instance-wide defaults

under the T383838[reticulum] section of the configuration file, or on a per-

interface basis under the relevant interface configuration section.